Subject: APPN HPR Encapsulation over Frame-Relay

From: "jim (j.) cobban" <[email-masked]>
Date: Wed, 14 Feb 1996 15:52:00 -0500

Section A.2.2 of the HPR specification details the encapsulation for HPR over
Frame Relay.  In attempting to implement this encapsulation we have
encountered a performance problem because it forces the RTP header to be on
an odd boundary, thus negating all of the design work in this header to
ensure that everything is word aligned.

Laying this encapsulation out word by word in the case of the last hop, where
there is only one ANR label, since this is the only case where the RTP header
is going to be received, the frame looks like:

    +---------------+---------------+---------------+---------------+
byte|       0               1       |       2       |       3       |
word+---------------+---------------+---------------+---------------+
 0  |             DLCI              |   UI (0x03)   |  NLPID (0x08) |
    +---------------+---------------+---------------+---------------+
 1  |        L2ProtId=0x5081        |        L3ProtId=0x7085        |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+---------------+
 2  |1 1 0|0 0|TPF|0|0 0 0 0|T|sld|0|   ANR Label   |   0xFF(delim) |
    +-----+---+---+-+-------+-+---+-+---------------+---------------+
 3  |0 0 0 0 0 0 0 0|    Start of RTP Header ...
    +---------------+

On our hardware, and I suspect on that of many members of the AIW, an HDLC
frame is received and placed in a word aligned buffer.  Everything in the RTP
header is aligned on a multiple of four bytes relative to the start of the
header, through to, and including, the FID 5 Transmission Header.  This
encapsulation defeats that.

You may argue that I have made an assumption that the final ANR label will be
only one byte long.  Firstly that is the length of the final ANR label in the
SNAP-APPN product from DCL, which is the basis of many of our
implementations.  Secondly there is no motivation for a longer label.  The
only purpose of this final ANR label is to direct the frame to a specific
instance of RTP.  There is no obvious reason to have a large number of
instances of RTP.  Indeed the only reasons that I can think of to have more
than one are to support multi-processor configurations, or maybe to have
multiple dispatching priority levels.  The second is unlikely because RTP
misbehaves if it is not at one of the highest dispatching priorities in the
processor.  Thirdly the encapsulation in the architecture will work if the
final ANR label is a multiple of 4 bytes long, however a 4 byte final ANR
label will cause LAN based implementations, our bread and butter, to have a
bad alignment of the THDR.

On our LAN implementation, to permit efficient processing while still
supporting the variable length routing information field, the LAN interface
inserts a buffer break between the end of the MAC header (including RI field)
and the beginning of the LLC field.  I cannot think of any other
implementation which will handle the variable length RI field without
destroying the alignment of the following data.  This technique is only
required on LANs which use source-routing.  On other LANs the MAC header is a
fixed length, so it is easy to ensure that the LLC header starts on a word
boundary.  So we are guaranteed that the LLC field begins on a 4 byte
boundary.  Then the HPR header with a 4 byte final ANR label looks like:

    +---------------+---------------+---------------+---------------+
byte|       0               1       |       2       |       3       |
word+---------------+---------------+---------------+---------------+
 0  |   DSAP(0xC8)     SSAP(0xC8)   |   UI (0x03)   |1 1 0|0 0|TPF|0|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+---------------+
 1  |0 0 0 0|T|sld|0|                   ANR Label                   |
    +-------+-+---+-+-------+-+---+-+---------------+---------------+
 2  |   ANR Label   |   0xFF(delim) |0 0 0 0 0 0 0 0|   Start of RTP Header ...
    +---------------+---------------+---------------+------------...

That is with a 4 byte final ANR label there is no way to arrange for the RTP
header to be on a word boundary.  By contrast if a 1 byte final ANR label is
used the header looks like:

    +---------------+---------------+---------------+---------------+
byte|       0               1       |       2       |       3       |
word+---------------+---------------+---------------+---------------+
 0  |   DSAP(0xC8)     SSAP(0xC8)   |   UI (0x03)   |1 1 0|0 0|TPF|0|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+---------------+
 1  |0 0 0 0|T|sld|0|   ANR Label   |   0xFF(delim) |0 0 0 0 0 0 0 0|
    +-------+-+---+-+-------+-+---+-+---------------+---------------+
 2  |   Start of RTP Header ...
    +---...

I therefore conclude that there will be few if any implementations for which
a multibyte final ANR label is desireable.

However if instead of trying to be so clever as to save an LLC header, we
instead carry HPR over frame-relay using the same encapsulation that we have
been using for ISR, just as we do on all other media beside frame-relay, then
the encapsulation looks like:

    +---------------+---------------+---------------+---------------+
byte|       0               1       |       2       |       3       |
word+---------------+---------------+---------------+---------------+
 0  |             DLCI              |   UI (0x03)   |  NLPID (0x08) |
    +---------------+---------------+---------------+---------------+
 1  |        L2ProtId=0x4C80        |        L3ProtId=0x7085        |
    +---------------+---------------+---------------+-+-+-+---+---+-+
 2  |   DSAP(0xC8)     SSAP(0xC8)   |   UI (0x03)   |1 1 0|0 0|TPF|0|
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---------------+---------------+
 3  |0 0 0 0|T|sld|0|   ANR Label   |   0xFF(delim) |0 0 0 0 0 0 0 0|
    +-------+-+---+-+-------+-+---+-+---------------+---------------+
 4  |   Start of RTP Header ...
    +---...

With this, more conventional, encapsulation, the RTP header naturally falls
on a word boundary, and can therefore be efficiently processed on all
hardware.

The additional benefits of this encapsulation as I have stated them earlier
are:

  1) It is the same as the ISR encapsulation except for the substitution of
     UI for I frames, consistent with the LAN encapsulation.
  2) It simplifies the design of FRADs which need to merely strip off the
     LAN MAC header and replace it with the RFC1490 protocol identification
     header, without having to look into the LLC layer to decide which
     encapsulation to use.  This latter can only be performed if the FRAD
     monitors the XID exchange to determine that the pair of SAPs in question
     are being used for HPR.
  3) It permits multiplexing HPR pipes over a single Frame-Relay virtual
     circuit, thus reducing the total network cost.  The tariffs for
     Frame-Relay are heavily loaded against using multiple VCs.

By comparison the ONLY obvious advantage of the current encapsulation
specification is that it saves 3 bytes.  Think about it.  The specification
is trying to save 3 bytes on a frame where HPR has added between 20 and
several hundred bytes for the THDR and 12 bytes for the FID 5 header!

I therefore propose that the section A.2.2 be amended to specify the used of
L2 Protocol identifier 4C80 and an 802.2 LLC header containing a UI command
code.  The existing specification should be allowed to die.